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Abstract 

We study the problem of providing privacy- 
preserving access to an outsourced honest-but- 
curious data repository for a group of trusted users. 
We show that such privacy-preserving data access is 
possible using a combination of probabilistic encryp- 
tion, which directly hides data values, and stateless 
oblivious RAM simulation, which hides the pattern 
of data accesses. We give simulations that have only 
an O(logn) amortized time overhead for simulating 
a RAM algorithm, A, that has a memory of size n, 
using a scheme that is data-oblivious with very high 
probability assuming the simulation has access to a 
private workspace of size 0{n v ), for any given fixed 
constant v > 0. This simulation makes use of pseudo- 
random hash functions and is based on a novel hier- 
archy of cuckoo hash tables that all share a common 
stash. We also provide results from an experimental 
simulation of this scheme, showing its practicality. 
In addition, in a result that may be of some theo- 
retical interest, we also show that one can eliminate 
the dependence on pseudorandom hash functions in 
our simulation while having the overhead rise to be 
0(log 2 n). 



1 Introduction 



Clearly, the customers of such cloud computing ser- 
vices have an interest in security and privacy, par- 
ticularly for proprietary data. As a recognition of 
this interest, we note that, as of November 2010, 
the Amazon S3 and Microsoft Azure cloud platform 
have achieved ISO 27001 certification and Google's 
cloud computing service has SAS70 certification. In 
spite of these certifications, the companies that pro- 
vide outsourced data services nevertheless often have 
commercial interests in learning information about 
their customers' data. Thus, the users of such sys- 
tems should also consider technological solutions for 
maintaining the privacy of their outsourced data in 
addition to the assurances that come from certifica- 
tions and formal audits. 

Of course, a key component for users to main- 
tain the privacy of their data is for them to store 
their data in encrypted form, e.g., using a group key 
known only to the set of users. Simply encrypting 
the group's data is not sufficient to achieve privacy, 
however, since information about the data may be 
leaked by the pattern in which the users access it. 
For example, at the Oakland 2010 conference, Chen 
et al. [8 show that highly sensitive data, such as fi- 
nancial and health information, can be inferred from 
access patterns at popular financial and health web 
sites even if the contents of those communications are 
encrypted. 



Companies offering outsourced data storage services 
are defining a growing industry, with competitors 
that include Amazon, Google, and Microsoft, which 
are providing outsourced data repositories for indi- 
vidual or corporate users, with prices that amount to 
pennies per gigabyte stored. 



1.1 Group Access to Outsourced Data 

In this paper, we are interested in technological so- 
lutions to the problem of protecting the privacy of a 
group's data accesses to an outsourced data storage 
facility. In this framework, we assume that a trusted 
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group, G, of users shares a group key, K, with which 
they encrypt all their shared data that is stored at a 
semi-trusted data outsourcer, Bob. Furthermore, we 
assume that the users access their data according to 
a public indexing scheme, which Bob knows; hence, 
we can model Bob's memory, M, as in the standard 
RAM model (e.g., see [UGH [HUB]). 

Each time a user, Alice, in G, accesses Bob's mem- 
ory, she specifies an index i, and Bob responds with 
C = M[i]. Alice then performs the following (atomic) 
sequence of operations: 

1. She decrypts G using K, producing the plaintext 
value, P = Dx{C), that was stored in encrypted 
form at index i by Bob. 

2. She optionally changes the value of P, depending 
on the computation she is performing, producing 
the plaintext value, P' . 

3. She encrypts P' using a probabilistic encryption 
scheme based on K, producing ciphertext C = 
E K (P'). 

4. She returns C to Bob for him to store back in 
his memory at index i; that is, she directs Bob 
to assign M[i] 4— C. 

By using a probabilistic encryption scheme, the users 
in the group G ensure that Bob is computationally 
unable to determine the plaintext of any memory cell 
from that cell's contents alone. Also, it is unfeasible 
for Bob to determine whether two memory cells store 
encryptions of the same plaintext. 

1.2 Stateless Oblivious RAM Simula- 
tion 

In addition to using probabilistic encryption, the 
users in the group G also need to hide their data 
access patterns from Bob, so as to avoid inadvertent 
information leaks. To facilitate such information hid- 
ing, we formulate the privacy objective of the users in 
G in terms of the stateless oblivious RAM simulation 
problem. 

In this framework, we model the group G as a sin- 
gle user, Alice, who has a register holding the key 
K and a CPU with a private cache. Alice's interac- 
tions with Bob occur in discrete episodes in which she 
reads and writes a set of cells in his memory, using 
probabilistic encryption, as described above, to hide 
data contents. Alice's cache may be used as a private 
workspace during any episode, but it cannot store 
any information from one episode to the next. This 
requirement is meant to model the fact that Alice is 



representing a group of users who do not communi- 
cate outside of their shared access to Bob's memory. 
That is, each episode could model a consecutive set 
of accesses from different users in the group G. More- 
over, this requirement is what makes this framework 
"stateless," in that no state can be carried from one 
episode to the next (other than the state that is main- 
tained by Bob). 

To allow the group of users, which we model by the 
stateless Alice, to perform arbitrary computations on 
the data they share and outsource to Bob, we assume 
that Alice is simulating a RAM computation. We also 
assume the service provider, Bob, is trying to learn as 
much as possible about the contents of Alice's data 
from the sequence and location of all of Alice's mem- 
ory accesses. As mentioned above, however, he can- 
not see the content of what is read or written (since 
it is probabilistically encrypted). Moreover, Bob has 
no access to Alice's private cache. Bob is assumed to 
be an honest-but- curious adversary |12) . in that he 
correctly performs all protocols and does not tamper 
with data. 

We say that Alice's sequence of memory accesses 
is data- oblivious if the distribution of this sequence 
depends only on n, the size of the memory used by 
the RAM algorithm she is simulating, m, the size 
of her private cache, and the length of the access se- 
quence itself. In particular, the distribution of Alice's 
memory accesses should be independent of the data 
values in the input. Put another way, this definition 
means that Pr(S | M), the probability that Bob sees 
an access sequence, S, conditioned on a specific con- 
figuration of his memory, M, satisfies 

Pr(S|M) = Pr(S\M'), 

for any memory configuration M' ^ M such that 
\M'\ = \M\. 

Examples of data-oblivious access sequences for an 
array, A, of size n, in Bob's memory, include the fol- 
lowing: 

• Scanning A from beginning to end, accessing 
each item exactly once, for instance, to compute 
the minimum value in A, which is then stored in 
A[l]. 

• Simulating a Boolean circuit, C, with its inputs 
taken in order from the bits of A. 

• Accessing the cells of A according to a ran- 
dom hash function, h(i), as A[h(2)], 

^4[/i(n)], or random permutation, 7r(i), as 
A[n(l)],A[K(2)},...,A[n(n)}. 

Examples of computations on A that would not be 
data-oblivious include the following: 
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• Scanning A from beginning to end, accessing 
each item exactly once, to compute the index 
i of the minimum value in A, and then reading 
A[i] and writing it to A[l]. 

• Using a standard heap-sort, merge-sort, or quick- 
sort algorithm to sort A. (None of these well- 
known algorithms is data-oblivious.) 

• Using values in A as indices for a hash table, T, 
and accessing them as T[h(A[l})}, T[h(A[2])], . . ., 
T[/i(A[n])], where h is a random hash function. 
For example, consider what happens if the values 
in A are all equal and how unlikely the resulting 
collision in T would be. 

Note that this last example access pattern actually 
would be data-oblivious if the elements in A were al- 
ways guaranteed to be distinct, assuming the random 
hash function, h, satisfies the standard assumptions 
of the random oracle model (e.g., see [6]). 

1.3 Related Prior Results 

Data-oblivious sorting is a fundamental problem 
(e.g., see Knuth [19]), with deterministic schemes giv- 
ing rise to sorting networks, such as the impracti- 
cal 0(n log n) AKS network [3J [551 HH] as well as 
practical, but theoretically-suboptimal, sorting net- 
works [iniHE]- Randomized data-oblivious sorting al- 
gorithms running in O(nlogn) time and succeeding 
with high probability are studied by Leighton and 
Plaxton [5T] and Goodrich [15 . In addition, data- 
oblivious sorting is finding applications to privacy- 
preserving secure multi-party computations [3D], and 
it is used in all the known oblivious RAM simulation 
schemes (including the ones in this paper). 

In early work on the topic of oblivious simula- 
tion, Pippenger and Fischer |27] show that one can 
simulate a Turing machine computation of length 
n with an oblivious Turing machine computation of 
length O(nlogn), that is, they achieve an amortized 
O(logn) time and space overhead for this oblivious 
simulation. 

More recently, Goldreich and Ostrovsky [T5] show 
that a RAM computation using space n can be simu- 
lated with an oblivious RAM with an amortized time 
overhead of 0(log 3 n) per step of the original RAM 
algorithm and space overhead of O(logn). Goodrich 
and Mitzenmacher |16] improve this result by showing 
that any RAM algorithm, A, can be simulated in a 
data-oblivious fashion, with very high probability, in 

In this paper, we take the phrase "with very high proba- 
bility" to mean that the probability is at least 1 — 0(l/n d ), 
for any given fixed constant d > 1. 



an outsourced memory so that each memory access 
performed by A has a time overhead of 0(log 2 n), 
assuming Alice's private cache has size 0(1). Their 
scheme has a space overhead of 0(1). Incidentally, 
in the recent CRYPTO 2010 conference, Pinkas and 
Reinman [25J also claim an oblivious RAM simula- 
tion result having a time overhead of 0(log 2 n), but 
there is a flaw in this version of their scheme0 

In addition to these stateless oblivious RAM sim- 
ulation schemes, Williams and Sion [3T] show how to 
simulate a RAM computation with an oblivious RAM 
where the data owner, Alice, has a stateful private 
memory of size 0(y/n), achieving an expected amor- 
tized time overhead of 0(log 2 n) using O(nlogn) 
memory at the data provider. In addition, Williams 
et al. [32] claim a method that uses an 0(i/n)-sized 
private cache and has O(lognloglogn) amortized 
time overhead, but Pinkas and Reinman |26| have 
raised concerns with the assumptions and analysis of 
this result. 

Goodrich and Mitzenmacher |16) provide a stateful 
RAM simulation scheme that achieves an overhead 
of O(logn) and is oblivious with very high probabil- 
ity. Their scheme assumes that Alice maintains state 
from one episode to the next in a private cache of size 
0{n u ), for any given fixed constant v > 0. Boneh et 
al. [7] also propose a scheme that uses a state. They 
achieve an amortized overhead of 0(1) but using a 
state of size O(^nlogn). However, this state is es- 
sential to the efficiency of both simulation schemes. 
Thus, these methods are not applicable to the prob- 
lem of providing privacy-preserving group access to 
an outsourced data repository. 

Returning to stateless oblivious RAM simulation, 
we note that Ajtai [3] has a recent oblivious RAM 
simulation result that shows that a polylogarithmic 
factor overhead in time and space is possible with- 
out cryptographic assumptions about the existence 
of random hash functions, as is done in the previous 
oblivious RAM simulation cited above. Damgard et 
al. |10j improve this result further, showing that a 
time overhead of 0(log 3 n) is possible for oblivious 
RAM simulation without using random functions. 

In addition to the above-mentioned upper-bound 
results, Beame and Machmouchi [5J show that if the 
additional space utilized in the simulation (besides 
the space for the data itself) is sufficiently sublinear, 
then the overhead for oblivious RAM simulation has 
a superlogarithmic lower bound. Such bounds don't 

2 The scheme of Pinkas and Reinman allows the adversary, 
Bob, to distinguish with high probability an access sequence 
that reads the same memory location over and over from one 
that accesses each memory cell exactly once. This flaw is ex- 
pected to be repaired in the journal version of their paper. 
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Table 1: Comparison of Oblivious RAM simulations. 





User 


User State 




Amortized Access 




Memory 


Size 


Overhead 


Goldreich and Ostrovsky [13J 


0(1) 




0(nlog n) 


0(log 3 n) 


Williams and Sion [3"T| 


O(Vn) 


o(vs) 


0(nlog n) 


0(log 2 n) 


Goodrich and Mitzenmacher [16] (1) 


0(1) 




0{n) 


0(log 2 n) 


Goodrich and Mitzenmacher [16] (2) 


0(n u ) 


0{n v ) 


0(n) 


O(logn) 


Boneh et al. [7] 


0(y/n logn) 


0(\/n\ogn) 


0(n) 


0(1) 


Our result 


0(n") 




0(n) 


O(logn) 


Our result (w/o random oracle) 


0(n") 




0(n) 


0(log 2 n) 



apply, of course, to a simulation that uses 0(n) addi- 
tional memory, as is common in the efficient schemes 
mentioned above. 

We provide a summary of the Oblivious RAM sim- 



ulation schemes and compare with ours in Table 1.3 



Note that the schemes that maintain a state cannot 
be used to hide a pattern of access by a group of users 
which is one of the challenges we address in this pa- 
per. 

1.4 Our Results 

We give an efficient method for simulating any RAM 
algorithm, A, in a stateless fashion with a time over- 
head of 0(log n) and space overhead of O(l), using an 
access sequence that is data-oblivious with very high 
probability, where n is the size of the RAM memory. 
Our methods assume that Alice has a private cache of 
of size 0(n v ), for any given fixed constant v > 0, but 
she uses this cache only as a private "scratch space" 
to support computations she performs during each 
episode. Alice is not allowed to maintain state in her 
private memory from one episode to the next. Thus, 
this simulation scheme is applicable to the problem 
of simulating access to a shared data repository by 
a group of cooperating users that all share a secret 
key. Moreover, the assumption about the size of Al- 
ice's scratch space is motivated by the fact that even 
handheld devices have a reasonable amount of local 
memory. For example, if we were to set v = 1/4, 
then our simulation would allow a collection of de- 
vices having memories with sizes on the order of one 
megabyte to support privacy-preserving access to an 
outsourced data repository whose size is on the order 
of one yottabyte. 

Like the previous oblivious RAM simulation 
schemes mentioned above, our scheme uses a hier- 
archy of hash tables, together with a small set of 
pseudorandom hash functions, to obfuscate the ac- 
cess pattern of the algorithm A (which need not be 



specified in advance) . The main idea of our scheme is 
to maintain these hash tables as cuckoo hash tables 
that all share a single stash of size O(logrt). While 
conceptually simple, this approach requires a new, 
non-trivial analysis for a set of cuckoo tables sharing 
a common stash. In addition, an important techni- 
cal detail that simplifies our construction is that we 
make no use of so-called "dummy" elements, whereas 
the previous schemes used such elements. 

In practice, the set of pseudorandom hash func- 
tions could be implemented using, e.g., keyed SHA- 
256 functions [TT]. Nevertheless, we also show that 
our construction can be used to simulate a RAM com- 
putation with an overhead of 0(log 2 rt) without the 
use of pseudorandom functions, which may be of some 
theoretical interest. 

Finally, we provide experimental results for a sim- 
ulation of our scheme, which show the practical effec- 
tiveness of the approach of using a shared stash. In 
particular, our experimental prototype simulates the 
dynamic evolution of the hierarchy of hash tables and 
our experimental analysis shows the threshold values 
at which the shared stash becomes effective. 



2 Theory Background 

For our results, we rely on general methods for data- 
oblivious simulation of a non-oblivious algorithm on 
a RAM. As mentioned above, the seminal theoreti- 
cal framework for such simulations was presented by 
Goldreich and Ostrovsky [T3] , who store keys in a hi- 
erarchy of hash tables of increasing size, each being 
twice the size of the previous one. For n items there 
are O(logn) levels, each level being a standard hash 
table with 2 l buckets for some i, and each bucket 
containing up to O(logn) keys in order to cope with 
collisions within the hash table. In this construction 
the total size of all the tables is O(nlogn). To per- 
form a lookup, the first level is scanned sequentially, 
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and in each of the other levels, a bucket chosen by 
the hash function for that level acting on the key 
(or, if the item is found at an earlier level, a random 
dummy key) is scanned. The item is subsequently re- 
encrypted and re-inserted into the first level. It is im- 
portant to note that at all levels a bucket is scanned 
even if the key is found early, to maintain oblivious- 
ness. As levels fill, keys must be shifted down to 
subsequent levels. The details of the original scheme 
are rather complex; for further details see the original 
paper [T3]. 

Recently, a more efficient simulation approach for 
this problem was outlined by Goodrich and Mitzen- 
macher |16) . The primary difference in this new line 
of work is the use of cuckoo hash tables in place the 
standard hash tables used originally in [13]. We 
therefore now present some background on cuckoo 
hashing. 

As introduced by Pagh and Rodler [21] , in standard 
cuckoo hashing we utilize two tables, each with m 
cells, with each cell capable of holding a single key. 
We make use of two hash functions hi and h 2 - We 
assume that the hash functions can be modeled as 
completely random hash functions. The tables store 
up to n items, where m = n(l + e) for some constant 
e > 0, yielding a load of (just) less than 1/2; keys 
can be inserted or deleted over time as long as this 
restriction is maintained. 

A key x (which we may also refer to as an "item" 
or "element" ) that is stored in the hash tables must 
be located at either h\{x) or h 2 (x). As there are only 
two possible locations for a key, lookups take constant 
time. To insert a new key x, we place x in the cell 
h\(x). If the cell had been empty, the operation is 
complete. Otherwise, key y previously in the cell is 
moved to ^(y)- This may in turn require another 
key to be moved, and so on, until a key is placed 
in an empty cell. We say that a failure occurs if, 
for an appropriate constant c, after clogn steps this 
process has not successfully terminated. Suppose we 
insert an nth key into the system. It is known that: 

• The expected time to insert a new key is bounded 
above by a constant (that depends on e). 

• The probability that a new key causes a failure is 
6(l/n 2 ) (where the notation hides a dependence 
on e). 

See Figures [T] and [2] for examples. 

Before considering ways to reduce the probabil- 
ity of failures to something more suitable, we briefly 
mention that there are several natural variations of 
cuckoo hashing, many of which are described in a sur- 
vey article by Mitzenmacher [22] . Variations include 
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Figure 1: The top of the figure represents a cuckoo 
hash table. Keys are placed in one subtable; the ar- 
row for each key points to the alternate location for 
the key in the other subtable. Key G is inserted, 
leading to the movement of several other keys for G 
to be placed, as shown in the bottom of the figure. 
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Figure 2: Key G is to be inserted, but it cannot be 
placed successfully. (Seven keys have only six loca- 
tions.) This leads to a failure, or if there is a stash, 
then G can be placed in a stash. 

using more than two choices, using cells that hold 
more than one key, and so on. For our purposes, it 
suffices to understand standard cuckoo hashing, along 
with idea of a stash [17j . 

A stash represents additional memory where keys 
that would cause a failure can be placed in order to 
avoid the failure; with a stash, a failure occurs only 
if the stash itself overflows. As shown in [T7], the 
failure probability when inserting the nth key into 
a cuckoo hash table can be reduced to 0(l/n fe + 2 ) 
for any constant k by using a stash that can hold 
k keys. Using this allows us to use cuckoo hash ta- 
bles for any polynomially bounded number of inserts 
and deletions using only a constant-sized stash. To 
search for an item, we must search both the two table 
locations and the k stash locations. In the context of 
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oblivious simulation, we can search the stash simply 
by reading each stash location. 

As we have stated, however, in order to perform our 
oblivious simulation, we will make use of a hierarchy 
of cuckoo hash tables to hold n items. The small- 
est of these hash tables may be much smaller than 
n, which can lead to problems in our setting] For 
example, if the smallest hash table is of size x, then 
even using a stash of size k leads to a failure probabil- 
ity of 0(l/x k+2 ). If x is for example polylogarithmic 
in n, then for any constant k 7 the failure probability 
is f2(l/n), and therefore over the insertion of n items, 
we would expect failures to occur. In order to deal 
with this problem, Goodrich and Mitzenmacher [TS] 
extend the analysis of [T7 to stashes of logarithmic 
size, showing that even for suitably large table sizes 
x that are only polylogarithmic in n, and stashes of 
size k = O(logn), the failure probability is 0(x~ ak ) 
for a suitable constant k. This suffices to yield super- 
polynomially small failure rates. 

In fact, we need to extend this result even fur- 
ther here. In [T^], Goodrich and Mitzenmacher use a 
logarithmic-sized stash at each level. We explain here 
that it suffices to use a single logarithmic-sized stash 
for all levels. That is, while there's a non-trivial prob- 
ability of at least one layer in our hierarchy requiring 
a stash of size 0(1), over the logarithmic number of 
layers only a stash of logarithmic size is actually nec- 
essary. We will use this in our construction in Sec- 
tion [3] We now briefly explain why, if we consider 
the sum of the number of items placed in the stash 
at all possible levels in our construction, this will be 
at most O(logn) with high probability. 

The key is the following argument. As shown in 
[16] , at a level of size x cells (where x is f2(log 7 n)), 
the probability that the stash for that level exceeds a 
total size s is x~ n ( s '. Further, as long as the hashes 
for each level in our construction are independent, 
we can treat the required stash size at each level is 
independent, since the number of items placed in the 
stash at a level is then a random variable dependent 
only on the number of items appearing in that level. 

Now consider any point of our construction and 
let Si be the number of items at the ith level that 
need to be put in the stash. It is apparent that Si 
has mean less than 1 and tails that can be domi- 
nated by a geometrically decreasing random variable. 
This is sufficient to apply standard Chernoff bounds. 
Formally, let X\ , Xi , . . . , X( be independent random 
variables with mean 1 geometrically decreasing tails, 
so that Xi = j with probability 1 / 2 J for j > 1. Then 
the calculations of [16 imply that the Xi stochasti- 

3 This is also at the heart of the flaw in the CRYPTO2010 
version of the Pinkas and Reinman paper |26| . 



cally dominate the Si , and we can now apply standard 
Chernoff bounds for these random variables. Specifi- 
cally, noting that Xi can be interpreted as the number 
of fair coin flips until the first heads, we can think of 
the sum of the Xi as being the number of coin flips 
until the £th head, and this dominates the number 
of items that need to be placed in the stash at any 
point. When I — O(logn), as is the case here as 
there are only O(logn) levels of hash tables in our 
construction, then for any constant 71 there exists a 
corresponding constant 72 such that the l\h head oc- 
curs by the (72 logn)'th flip with probability at least 
1 — 1/n 71 . (See, for example, [23] Chapter 4].) Hence 
we can handle any polynomial number of steps with 
high probability, using a stash of size only O(logn) 
that holds items from all levels of our construction. 

3 Simulating a RAM Algo- 
rithm Obliviously 

In this section, we describe and analyze two schemes 
for stateless oblivious RAM simulation. 

3.1 Simulation Using Pseudorandom 
Functions 

We begin with a construction that uses pseudoran- 
dom functions and is secure against a polynomially 
bounded adversary. 

Given a RAM algorithm, A, the main goal of our 
oblivious simulation of A is to hide the pattern of 
memory accesses that are made by A. As mentioned 
111 Section [5] we follow the general framework intro- 
duced by Goldreich and Ostrovsky [13], which uses a 
hierarchy of hash tables. 

Let n be the number of memory cells of the RAM. 
We view each such cell as an item consisting of a pair 
(x, v), where x £ {0, ■ • • , n — 1} is the index and v is 
the corresponding value. Our data structure stored 
at the server has three components, illustrated in Fig- 
ure]^ The first component is a cache of size O(logn), 
denoted by Q. The second component is a hierarchy 
of cuckoo hash tables, T = (Ti, . . . , Tj,), where the 
size of Ti is twice the size of Q, each table T! i+1 is 
twice the size of table Tj, and Tl is the first table 
in the sequence of size greater than or equal to n. 
Thus, L is O(logn). The third component is a stash, 
S, shared between all the above cuckoo tables. 

RAM items are stored in the data structure in en- 
crypted form. We use a semantically secure prob- 
abilistic encryption scheme, which results in a dif- 
ferent ciphertext for the same item each time it is 
re-encrypted. Also, the server is unable to determine 
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Figure 3: Illustration of the data structure stored at the server for oblivious RAM simulation using pseudo- 
random functions. In the access phase of the simulation, all the items in the cache, Q and the stash, S, plus 
two items for each cuckoo table T are read by the server. The locations accessed by the server are visualized 
as gray- filled rectangles. 



whether two ciphertexts correspond to the same item. 
The stash S is handled in a similar manner whenever 
we search in it for an item. 

We use a family of pseudorandom functions param- 
eterized by a secret value, fcj, for each table, T t , such 
that no value fcj is revealed to the server. In particu- 
lar, ki is stored in encrypted form for each table T, 
so that each user can read fcj, decrypt it, and then 
use it to provide the two hash functions, h\ and /12, 
employed by the cuckoo table, T, to determine the 
location of items. In particular, a memory item (x, v) 
is mapped to locations h\{x) and h,2{x) in T, by the 
cuckoo scheme (and stored in one of these two loca- 
tions or in the common stash, S). 

The data structure is initialized by storing all the n 
RAM items into cuckoo table Tl- Each memory ac- 
cess defined by algorithm A corresponds to an episode 
in our simulation. An episode consists of two phases, 
an access phase and a rebuild phase. 

Suppose algorithm A calls for an access to memory 
item (x,v). The access phase consists of a search for 
x in the cache, Q, then in the stash, S, and contin- 
ues with a two-cell cuckoo lookup in each of T\ to 
Tl until we find the first item with index x. Once we 
have found this item, we have achieved the goal of our 
search, of course. Nevertheless, for the sake of obliv- 
iousness, we simulate continuing the search through- 
out the entire data structure. Namely, we always 
traverse completely Q and S, and we perform two- 
cell cuckoo accesses in tables T\ through Tl- How- 
ever, after the item is found, we simply access two 
distinct, independent uniformly chosen random loca- 
tions in each remaining cuckoo table. 



Once we have completed the access phase, which 
takes O(logn) time, we then switch to the rebuild 
phase. We begin by adding or replacing a copy of 
the found item into cache Q, possibly changing its 
value in the case of a write operation. To assure 
obliviousness, we exhaustively scan Q in a sequen- 
tial manner and re-encrypt and rewrite all its items. 
Thus, the server cannot distinguish which item was 
accessed and whether it was modified. 

We note briefly that if the item is in the stash, 
we can obliviously remove it from the stash when 
placing it into Q, to help make sure the stash does 
not overflow. One natural approach is to have stash 
cells have an associated "clean" or "dirty" bit, which 
is encrypted along with the rest of the item. A clean 
cell can store an item; a dirty cell is currently being 
utilized. When an item is found and replaced into Q, 
we can set the cell to clean in the stash. 

After adding enough items, cache Q will eventually 
overflow. We remedy the overflow by moving all the 
elements of Q to cuckoo table T\ , including those as- 
sociated with empty locations. However, in order to 
maintain obliviousness, we do not wait for an overflow 
to occur and instead perform the move after a number 
of accesses equal to the size of Q. The moving down 
of elements cascades down through the hierarchy of 
cuckoo tables at a fixed schedule by periodically mov- 
ing the elements of Tj_i into Tj at the earliest time 
Tj_i could have become full. Also, suppose that we 
are going to move elements into table T for the sec- 
ond time, then we instead move the elements into 
table Tj_|_i. Moreover, we continue applying this rule 
for i — 1,2,..., until we are copying the elements 
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into a table for the first time or we reach Tj,. Thus, 
the process of copying elements into a cuckoo table 
occurs at deterministic instances, depending only on 
the place we currently are at in the access sequence 
specified by algorithm A. 

In order to move m elements from a table Ti into 
a cuckoo hash table Tj+i obliviously, we use an algo- 
rithm of (16j to obliviously sort the items using 0(m) 
accesses to the outsourced memory, assuming we have 
a private workspace of size 0(n v ), for some constant 
v > 0, and m > logn, which is always true in our 
case. This allows us to remove duplicate items and 
use another algorithm of [IF] to obliviously construct 
a cuckoo table of size m and an associated stash, S', 
of size O(logn) in O(m) time, with very high prob- 
ability, while utilizing the private workspace of size 
0{n v ). Given this construction, we then read S and 
S' into our private workspace, remove any duplicates 
and merge them into a single stash S (which will suc- 
ceed with very high probability, based on the anal- 
ysis we have given above), and write S back out in 
a straightforward oblivious fashion. Note that in or- 
der to assure obliviousness in subsequent lookups, ta- 
ble T,+i is rebuilt using two new pseudorandom hash 
functions selected by the client by replacing parame- 
ter ki + i with a new secret value. 

Any access performed in our simulation will even- 
tually lead to O(logn) table rebuilds, with each el- 
ement in a rebuild being charged with a constant 
amount of work; hence, the total amortized over- 
head of all rebuild phases is O(logn). Therefore, the 
total amortized time overhead of the entire simula- 
tion is O(logn). Moreover, it is easy to see that the 
space used by the data structure stored at the server 
is 0{n). 

Let us therefore consider the obliviousness of this 
scheme. As we have already observed, the rebuild 
phase is clearly oblivious, so any potential dependen- 
cies on input values would have to come in the access 
phase. Recall that in the access phase, we search in 
S, Q, and do a two-table cuckoo access in T±, . . . ,Tl. 
Moreover, because we move the found item into Q af- 
ter each access, and we switch to performing random 
table lookups once we have found the item, we are 
guaranteed never to repeat a two-cell cuckoo lookup 
in any table, Ti, for the same item x. In addition, 
each such lookup is an independent uniformly ran- 
dom access to a table (either from our assumption 
about hi and h 2 being distinct random hash functions 
for each table or because we already found the item 
and are making random accesses explicitly). We per- 
form 0(|Tj|) such lookups before we empty Ti; hence, 
the obliviousness of our access sequence depends on 
the inability of the adversary, Bob, of telling if we 



are doing a search for an actual item or performing 
a random access for the sake of obliviousness. That 
is, with high probability, Bob should not be able to 
determine whether the item was in S, Q, or some Tj 
at the point we found it. Note that this ability de- 
pends solely on whether or not the 0(|2}|) accesses 
we made to Tj, together with searches in the shared 
stash S, would correspond to valid cuckoo lookups in 
T.- L for some set of items. Of course, this is the same 
as the event that inserting all these elements into T; 
would form a valid cuckoo table, with shared stash S, 
which we have already observed (in Section [2]) is an 
event that occurs with very high probability. Thus, 
our scheme is oblivious with very high probability. 

3.2 Simulation Without Pseudoran- 
dom Functions 

We can adapt our simulation to avoid the use of ran- 
dom functions by employing an elegant trick due to 
Damgard et al. |10j . albeit now further simplified to 
avoid the use of dummy nodes, which would add an 
extra level of complication that our scheme doesn't 
require. 

The main idea is to place a complete binary tree, B, 
on top of all the memory cells used in the algorithm 
A, and access each memory cell x by performing a 
binary search from the root of B to the leaf node cor- 
responding to x. That is, we associate each memory 
cell item used by A with a leaf of B, define B to 
have height [log n] , and include information at each 
internal node v of B so that a search for x can deter- 
mine in O(l) time whether to proceed with the left 
child or right child of v. In our case, we store each 
of the nodes of B in our hierarchy of tables, similar 
to what is described above, with the shared stash, S, 
the cache, Q, and the set of cuckoo tables, T\ to Tj,. 
(See Figure g) 

The main difference of this scheme with that given 
above is that in this case we no longer use random 
hash functions, hi and h 2 , to determine the loca- 
tions of each element i in a cuckoo table Tj. In- 
stead, we simply choose two distinct, independent 
uniformly random locations, i\ and i 2 , in the respec- 
tive two sides of T, and associate these with i as a 
tuple (x,ii,i2), which now represents the element x 
in our table. 

Initially, all the nodes of B are stored in this way 
in Tl, and for each such internal node v, we include 
in u's record pointers to the two random indices (and 
table index) for v's left child and pointer to the two 
random indices (and table index) for v's right child. 
Such pointers can be built obliviously by 0(1) calls 
to oblivious sorting once we have placed all the nodes 
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Figure 4: Illustration of the data structure stored at the server for oblivious RAM simulation without using 
pseudorandom functions. The binary tree is shown conceptually on the right and in terms of the storage 
locations of its nodes on the left. The storage locations for the nodes of the binary tree, B, are visualized as 
gray-filled rectangles. In the access phase of the simulation for a non-root node, all the items in the cache, 
Q and the stash, S, plus two items for each cuckoo table T, are read by the server. 



into Tl- Moreover, we will maintain such pointers 
throughout our simulation. In addition, we store the 
root r of B separately, as it is accessed in every step 
of our simulation. 

Let us consider, therefore, how an access now oc- 
curs. The critical property, which we maintain in- 
ductively, is that, for each node v in B, which, say, is 
stored in Tj as its earliest (highest) location in our hi- 
erarchy, all the ancestors of B are stored in the tables 
Ti, . . . , Tj, or in r, S, or Q. 

Our access for a memory cell x now occurs as a 
root-to- leaf search in B. We begin by searching in 
r to identify the two random indices and the table 
index for each of r's children. Based on the value 
of x, we need to search next for either the left or 
right child of r, so let i\ and i 2 be the two random 
indices for this node, w, and let j be the index of the 
highest table Tj storing w (with j = if w € Q and 
j = — 1 if w G S). We next search in S and Q for 
w, and then proceed in T\ through Tl. Of course, 
we already know the table where we will find w. So, 
for each table Tk with k ^ j, we simply access two 
random locations in Tk for the sake of obliviousness. 
For Tj itself, we look in locations Tj[ii] and Tj[i 2 ) to 
find the cell containing the record for w. If w is not a 
leaf node, we repeat the above lookup search for the 
appropriate child of w that will lead us to the node 
storing x. 

Once we have done our lookup for x, and have ac- 
cessed a root-to-leaf set of nodes, 

W = {w 1 ,W 2 , ■ ■ . ,U>logn}) 



in the process, we perform a rebuild phase for W, 
as in the above construction based on random hash 
functions, except that we use random locations for all 
the nodes we move rather than use random functions. 
Note that by our induction hypothesis, if we move a 
set of nodes into a table Ti, then all the pointers for 
these nodes are either in Tj itself (hence, can be iden- 
tified after 0(1) calls to oblivious sorting, which takes 
0(n) memory accesses by the algorithm of 16J) or at 
lower levels in the hierarchy (hence, these pointers 
don't change by our move into Tj). Moreover, all the 
nodes of W move as a group. Thus, any root-to-leaf 
path in B must be stored in the tables T\ to Tl, plus 
the queue Q and stash S, in a way that satisfies our 
induction hypothesis. 



The lookup for an element x now requires search- 
ing for O(logn) nodes of B in our hierarchy, which 
costs an amortized overhead of O(logn) time each. 
Thus, each lookup costs us an amortized overhead 
of 0(log 2 n) time. The obliviousness of this simula- 
tion follows from an argument similar to that given 
above for the obliviousness for our method that uses 
random hash functions. Therefore, we can perform 
a stateless oblivious RAM simulation without using 
random hash functions with an amortized time over- 
head of (9(log 2 n), assuming a private workspace of 
size 0(n u ) for some constant v > 0. 
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4 Performance 

We have implemented a preliminary prototype of our 
method for oblivious RAM simulation based on pseu- 



dorandom functions (Section 3.1 ) with the goal of es- 



timating the size of the stash S needed to avoid fail- 
ures during the rebuild phase. A failure can happen 
when we move elements from table Tj to T i+ i and 
the stash overflows, in which case we need to rebuild 
table Ti + i. In this section we present experimental 
results and show that for a small constant s, a stash 
of size slogn is enough to avoid failures. 

Our prototype simulates the dynamic evolution of 
the hierarchy of hash tables during the access and re- 
build phases, omitting the steps that maintain obliv- 
iousness (e.g. copying the stash to the client's side). 
We maintain a stash S, a cache Q of size logn and 
a hierarchy of O(logn) cuckoo hash tables T\ to Tl, 
where L is the smallest i such that 2 l log n > n. Ti 
consists of two hash tables of size (1 + e)2' log n with 
hash functions h\ and h\ ■ Every memory access is fol- 
lowed by the insertion of the corresponding element 
into Q. If the item was retrieved from stash S, it is 
first copied to Q and then is removed from S. We 
move all the elements of Q to T\ when the number 
of performed accesses is a multiple of log n. Simi- 
larly, we move all the elements of Tj to T i+1 when the 
number of performed accesses is a multiple of 2 Z log n. 
New hash functions are picked for both tables during 
this phase. During the insertion, an item is placed 
into the stash if after clogn moves it has not found 
an empty cell in the table; we experiment using c = 2. 
We insert an item into the stash only if it is not al- 
ready present there. 

Our prototype is implemented in Java. To 
generate hash functions we use a variation of 
a method recommended in [TT], where h\(x) — 
SHA256(a; || seed, 1 ) mod n, and similarly for h\. 
The seeds are 64-bit long and were obtained using 
a SHA256 hash chain starting from an initial seed. 

We emphasize that in any implementation of our 
method there are various tradeoffs. For example, 
increasing the space (that is, using larger values of 
e) reduces the average time for an insertion and the 
failure probability, as it reduces the frequency with 
which items have to be put in the stash. Increasing 
the stash size reduces the failure probability at the 
expense of additional time to examine the stash at 
each step. Increasing the number of moves allowed 
before placing an item in the stash increases the time 
but lowers the failure probability. Our purpose here 
is not to explore this broad range of tradeoffs, but to 
demonstrate the feasibility of this approach; explor- 
ing finer tradeoffs is left as future work. 



We ran our simulation for up to 1024K (K = 1000) 
RAM items and a varying number of requests. Our 
experiments use a value of e of 0.1 and 0.2. For each 
experiment we recorded the lowest size of S that is 
needed to avoid a failure. In Figures [5] and [6] we show 
the fraction of trials out of 1000 that result in the 
stash overflow. Comparing the two figures, we see 
that overflows happen substantially more frequently 
with e = 0.1 than with e = 0.2, as one would expect 
since smaller tables lead to more collisions. Indeed, 
for e = 0.2 we found a stash size of less than logn 
was enough to avoid overflows completely in our lim- 
ited experiments. Also, a higher number of requests 
requires a slightly bigger stash since rebuilding hap- 
pens more often, leading to a larger maximum stash 
requirement. While much more extensive experimen- 
tation would be needed to determine suitable stash 
sizes that would avoid stash overflow for numbers of 
trials many orders of magnitude larger, recall that 
the probability of an additional item needing to be 
placed in a stash in a standard cuckoo table falls very 
quickly. We thus expect only slightly larger stash 
sizes for such improvements in robustness. 
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Figure 5: Failure rate in 1000 trials for n items and 
r requests with c = 2, e = 0.1. 



5 Conclusion 

We have given schemes for achieving privacy- 
preserving access, with very high probability, to an 
outsourced data repository for a group of trusted 
users. Our scheme assumes each user has a mod- 
est amount of private memory, of size 0(n u ), for 
any given fixed constant v > 0, which is used as 
a workspace for private computation and carries no 
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